Summary

Remove the hardcoded max_factor upper bound of 3.0 and read the actual limit from the network's config param 17 (max_stake_factor). Previously, nodectl rejected any max_factor above 3.0 even on networks (e.g. testnet) that allow up to 30.0.

Changes

Reading network limit

• ton_utils: add MAX_STAKE_FACTOR_SCALE constant and max_stake_factor_raw_to_multiplier() to convert the raw fixed-point value from param 17 to a float multiplier.
• config_params: add parse_config_param_16() and parse_config_param_17() for deserializing validator count limits and stake limits from the chain.
• client_json_rpc: add network_max_stake_factor_raw() and network_max_stake_factor_multiplier() methods to fetch the network cap via TON HTTP API.

Validation

• ElectionsConfig::validate(Option<f32>): accept an optional upper bound.
  • None (offline, e.g. AppConfig::load): only checks max_factor >= 1.0 — no upper cap, so configs written for high-limit networks still load.
  • Some(m) (service startup / reload): enforces max_factor ∈ [1.0, m] using the live network value.
• config elections max-factor CLI: fetches param 17 via RPC before saving and validates against the network limit.
• config wallet stake --max-factor CLI: same RPC-based validation before submitting the stake.
• RuntimeConfigStore (service): validates against network_max on initialize() and reload().
• runner::build_new_stake_payload: validates the raw max_factor in the stake payload against cfg17.max_stake_factor.

Tests

• test_elections_validate_max_factor_respects_network_cap — Some(3.0) rejects 5.0, Some(5.0) accepts it.
• test_elections_validate_none_allows_max_factor_above_default_cap — None accepts 25.0, Some(3.0) rejects, Some(30.0) accepts.
• Timing validation tests (sleep_period_pct, waiting_period_pct) updated to use validate(None).

Documentation

• README: updated config elections max-factor, elections config section, and config wallet stake table to reflect that the upper bound comes from config param 17, not a hardcoded 3.0.